1. Field of the Invention
The present invention relates generally to systems and methods for providing an embeddable mutual authentication mechanism and more particularly to systems and methods that address shortcomings of authentication mechanisms such as man-in-the-middle attacks and CSS overlay attacks and that can be used to implement a federated mutual authentication system across multiple sites and domains.
2. Description of Related Art
Many authentication systems, such as those used by secure websites, use a user's web browser as an input mechanism. Such systems face a challenge in that the client often cannot reliably determine whether an entity with which they are authenticating is a specific entity with which they intend to authenticate. Attackers are often able to trick users into entering their credentials into a website that looks like the intended entity with which they desire to authenticate. The attackers are thus able to capture a user's credentials and assume his identity when communicating with the intended entity. This type of attack is commonly called “phishing.”
Phishing attacks generally rely on a user having the mistaken impression that he is providing his credentials to the intended entity when in reality the page belongs to an imposter. Because of this, the most effective way for an entity to fight phishing attacks is to provide the user with some form of verification that the authenticating entity is in fact who it claims to be. A system in which the server authenticates itself to the client in addition to the client authenticating itself to the server is known as a mutual authentication system.
One simple, low cost and low barrier method of providing mutual authentication is through the use of a passphrase. It is important to note the difference between a password and a passphrase in this context. In this document, ‘password’ is used to refer to a form of credentials that a user supplies to a server; ‘passphrase’ is used to refer to any piece of digital information that can be used to authenticate a server to a client. Common examples of a passphrase in this context would be text, an image, an audio or video clip, or a piece of HTML. A passphrase should be something that is meaningful to the user but cannot be easily guessed by an attacker.
A simple example application of a passphrase would be to identify valid emails from an organization. Organizations often warn clients that they will not send important information or requests for data in an email. To identify emails that are valid, an organization could include the user's passphrase in all correspondence. The inclusion of the passphrase lets the user know that the email must have come from the entity with which he established the passphrase. In practice, it is not desirable to email a passphrase because the overwhelming majority of email is sent unencrypted over the Internet. This makes it possible for an attacker to capture these passphrases during transmission. Stolen passphrases are very dangerous, because, if an attacker has a user's passphrase, he can use it to convince even an astute user that he is the entity that he is imitating.
A more realistic and common example application of a passphrase is a website that requires authentication, such as a bank's website. In this example, the bank displays the passphrase on the same bank webpage that requests the user's credentials. The presence of the passphrase assures the user that the authenticating entity is not a phisher since only the actual bank could know the user's passphrase.
Although the web browser example does not have the obvious drawbacks of the email example, it is not perfectly secure either. One common attack is known as a man-in-the-middle (MITM) attack. In a common MITM phishing attack, the phishing site simply acts as a relay for the communication between the user and the desired server. The user is actually sending all requests to the phisher, but, after capturing any desired data from the request, the phisher relays the request to the server and then relays the server's response to the user. The user is thus able to communicate normally with the server and there is no obvious cause for suspicion. In the passphrase example, even though the user is sending requests to the phisher and not the server, the passphrase is displayed so the user continues to supply the requested credentials.
Another failing of the website example is that it is possible for an attacker to embed the actual authentication page in another page which is controlled by the attacker. The attacker's outer page can theoretically include active content such as JavaScript that can attack the embedded authentication page or extract information from it. In practice, all significant web browsers address this issue by implementing what is known as cross-domain security. This prevents dynamic content served by one domain from accessing or manipulating content served by another domain. Since the phisher's outer page is not served by the same domain as the authentication page, the browser should prevent the phisher's page from accessing any information. There is, however, a hole in this browser security. Although an attacking page cannot directly interact with a page served by another domain, it can layer HTML elements on top of the embedded content using a technology such as Cascading Style Sheets (CSS). As a simple example, consider an authentication page that uses an HTML form field to request a password. An attacking page could embed the authentication page, and then overlay its own password field directly on top of the authentication page's password field. The user sees the passphrase and assumes that all is well, but the password field that is visible actually sends the password to the phisher!
In the previous website example, the page that requested credentials from the user was hosted on a web server. This example becomes slightly more complicated if the page is instead a local file that needs to authenticate with a server. Users are often advised that they can thwart phishing attacks by checking the address of the website they are visiting and verifying that the address matches the domain with which they are trying to authenticate. If the file is stored locally, then this check provides no additional security. One example of an application that uses this type of authentication is an application designed to send encrypted emails. A mechanism for doing this is to send an HTML email that contains both the encrypted data and a form asking for the password to allow the message to be decrypted. There is no simple way for the user to verify that the HTML will not capture the password that is entered in this form. Even if the email comes from a trusted entity, an attacker could intercept the email during transmission and modify the HTML. The HTML could contact the server to display a passphrase to assure the user that the request is valid, but if the HTML has been tampered with by an attacker then the modified HTML could easily capture the passphrase in addition to any credentials that are entered.
An additional potentially undesirable aspect of mutual authentication using a passphrase is that every organization must implement such a system and record the passphrases of its users. For the organizations, this requires additional storage infrastructure and the administration of a complex authentication scheme. For the users, remembering which passphrase is correct for each organization that uses such a scheme could be confusing. Moreover, if a user's passphrase is stolen from one organization it could be used in an attack on that user for a different organization.